Skip to main content

Strategies for Migrating SharePoint Custom Script Solutions

Small flowchart to help you decide on how to proceed with your migration away from Custom Scripting

· 3 min read View Comments
Martin Jurran
Software Engineer - OSS, golang, .NET

Throwing out the deprecated Custom Scripting and replace it with something new and shiny

Throwing out the deprecated Custom Scripting and replace it with something new and shiny (Photo by the author)

If you are working with SharePoint Online, you should be aware that Custom Scripting solutions are being deprecated due to security concerns soon.

By November 2024, it will no longer be possible to prevent SharePoint from resetting custom script settings to their original value for all sites.

The recommended way to deal with Custom Scripting solutions by Microsoft is to migrate them into the SharePoint Framework (SPFx). There's other options.

In this article, we will be exploring the migration of custom scripting solutions in SharePoint Online.

Immediate Relief

Buying Time — Only until November 2024

Custom Script can be enabled or disabled at the site level, and the automatic 24-hour reset can be disabled at the tenant level.

While custom scripting solutions are being deprecated, there may be situations where you need to buy some time to get your application up and running again.

In these urgent situations, disabling the automatic reset may be a valid option. However, it’s important to understand that custom scripting solutions come with security risks.

Read more here: Allow or prevent custom script — SharePoint in Microsoft 365 | Microsoft Learn

Decision Flowchart

Flowchart supporting to make a decision for migration of Custom Scripting solutions (Photo by the author)

Flowchart supporting to make a decision for migration of Custom Scripting solutions (Photo by the author)

For your solution, it might not be the most effective option for migration to continue staying in the SharePoint ecosystem.

For instance, there is scenarios where it’s a good any easy decision to change your approach:

  • (1) Hosting static HTML assets that (a) do not change frequently, or (b) do not change at all.
  • (2) Single-Page-Applications without data connections to SharePoint or only use SharePoint of authentication.

For all other types of custom scripting solutions, migrating to SharePoint Framework (SPFx) should be a top priority.

More Resources

For those looking to migrate their custom scripting solutions to SharePoint Framework (SPFx), there are a variety of resources available to help guide you through the process. Microsoft has created several hands-on articles that walk you through real-life use cases and provide step-by-step.

Migrate existing Script Editor web part customizations to the SharePoint Framework | Microsoft Learn

Comments

View Comments